Nebula 2/Nebula Two.iso/Apps/ScreenSavers/BackSpaceViews/StarShipView.BackModule/README

Text File | 1995-06-12 | 5.6 KB | 128 lines

                        StarShipView BackSpace Module
                        (For NeXTstep 3.0 or higher)

1. Compiling:

    I wanted a module that could be completely built with PB. Double click
    the PB.project file. In Project Builder, simply do a build with
    install in the Args field for  NextStep 3.0. If you are compiling under
    3.1, select install from the target pull down menu and choose the
    appropriate cpu type from the options button.  It should install the
    StarShipView.BackModule in the ~/Library/BackSpaceViews in your home
    directory.If you want to include the Warp1 module, drag and drop the
    Warp1.bproj subproject onto the subprojects suitcase in ProjectBuilder
    and then do the compile.

    Important Notes:

    I am submitting a 3.0 and a 3.1 fat binary version. They
    need to be run with the compatible version of BackSpace. I have been
    told that doing the build install will not do the right things under
    3.2 so when I know what the changes are, I will update.

2 Internals:

    StarShip tries to simulate going through space in a starship.

    I had a idea to design a backspace module that would set
    up an environment that others could write modules for and that
    would be loaded in dynamically at run time. I include two separate
    modules called Celestial and Warp1. Celestial is really the
    main module and Warp1 was a quick module to show how
    other modules can be loaded and unloaded. I include Warp1 in the sources
    but I don't include it  in the project.

    StarShipView really doesn't unload modules. At start time it builds
    a list of all the bundle objects that are in the StarShipView.BackModule
    folder(bundle). It instantiates all the classes that it finds up front.
    I do provide a message to the freeResources method that is to be used
    to get rid of memory gobblers like tiff images and sounds that are just
    used for your module.

    There is a StarShipProtocol.h that includes the methods that must be
    implemented. I really should test the modules to see if they conform
    to the protocol but I haven't added that yet. The other "should be there",
    is to have a separate button on the inspector panel that fires up a
    separate info panel from the different modules. That way when your module
    is active the user could get specific info about your module.
    I do however provide a way to see on the inspector what module is currently
    running. If anyone could tell me the easy way to do this with a nib file,
    please let me know. I couldn't figure out how to free a loaded nib when
    the next module is being loaded. The other way I thought of was to build
    the scrollView from scratch. I didn't like that either. Another thing
    I thought of was that the slider labels in the inspector should be dynamic.
    That way each module could label the sliders any way they wanted.

    The Module that you write will be sent the outlet for the stars so that
    your module has control over starting and stopping them. You even have
    control over turning them off altogether. See the HideStars method
    in NewSpaceView.

    The border around the viewscreen actually moves 9 pixels back and forth to
    prevent screen burn in.


    I have defined variables to allow you to custom tailor the
    program. I've included them here.

NewSpaceView.m

    SCREENMOVE 1000  how often the screen border resizes
    LIGHTMOVE 10     how often the lights below the viewscreen move


Celestial.m
    MAXMULTBODY 10   maximum mutiple objects - randomly generated up to

TiffManager.m

    MAXIMAGESIZE 150  maximum size the scaled images will be
    SIZEINC  2          each animation frame is incremented by this amount
                      in pixels - starting at 1 pixel
                      The smaller, the more images are built into memory
                      but also the smoother the animation

CelestialCommon.h

    MAXANIMATIONS 4      maximum number of animations to be built for each
                      cycle - on larger memory machines you can up this


3:    The Celestial Module

    When the Celestial module is activated it starts building tiff images
    in memory(tiffManager object) and adds them to a list that is put in a
    storage object. The Celestial object acts as the controller and then
    takes the info in the storage object and creates and frees body objects
    as they fly through space. To do mutiple objects, it just creates more
    of them. The tricky part is for each body to set an avoidance rectangle
    in a storage object. That storage object is passed off to the stars
    object(NewSpaceView) who avoids drawing or erasing any stars there.

4:    The Warp1 Module

    I wrote this module very quickly without too much thought as to how
    good it looked. It really only serves as a second module to demonstrate
    how the modules can be switched between.

5:  Thoughts

    I strip out all alpha from the tiff images coming in. This makes everything
    go faster. It's ok to have alpha in your own tiff images cause I composite
    to a black background. I did discover a way to have the starShipView
    get running faster but it involved generating the animations to a
    single tiff image ahead of time. Since I use lists of tiff images and
    don't internally build a single tiff image (which could be done), it would
    have taken a bit more work to build that functionality into it. Also
    I didn't like the fact you would have all these huge files sitting around
    just to launch faster. Currently they would range from .5 meg to 1.2 meg
    each depending the the scheme to put all the images into one tiff image.
    Besides, the idea of a screen saver isn't really to sit and watch it,
    or is it? Anyways, I do hope someone will write some others to go along
    with these. If you have any questions, feel free to contact me. Enjoy!

    R.S. Brown
    [e-mail]